<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'The engine',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/08/19.jpg" alt="The bike path" class="framed-centred-image" width="649" height="480"/>
<section id="employment">
	<h2>Seeking employment</h2>
	<p>
		The job hunt continues, but there&apos;s nothing to say about that.
	</p>
</section>
<section id="Minetest">
	<h2>Minetest</h2>
	<p>
		I haven&apos;t touched a line of code today (aside from the code that builds this page, which is a hybrid of $a[PHP] and $a[XHTML]), but I can&apos;t help but let my mind wander to Palette Game when I&apos;m stuck performing mindless, repetitive tasks.
		I made a breakthrough today.
		I realised that I&apos;ve been letting <code>minestats</code> hold back development already, and development has hardly begun!
		I&apos;ve been ruling out ideas I otherwise liked because they&apos;d necessarily me incompatible with <code>minestats</code>.
		Instead of <code>minestats</code> being a roadblock to overcome, it needs to be the engine that drives and inspires development!
	</p>
	<p>
		I have a pull request for Minetest I need to write that will allow paletted nodes to drop different items depending on their palette index.
		If and when accepted, the infrastructure will have exactly the feature I need <code>minestats</code> to be able to rely upon without holding back Palette Game development.
		An equivalent feature could be added on a per-node basis by the mods that use it, but in that case, <code>minestats</code> wouldn&apos;t be able to read and account for it.
		Before sending the pull request, I need to code <code>minestats</code> to handle it properly, as well as add a quickly-erasable section that causes <code>minestats</code> to <strong>*add*</strong> the feature for now, so it can rely on the presence of said feature.
		Best case scenario: the pull request is accepted, so I remove the then-redundant feature from <code>minestats</code>.
		Worst case scenario: The pull request is either rejected or sits in limbo, never getting accepted nor technically declined, so I have to label some of my mods as not operating correctly unless <code>minestats</code> is installed.
		<code>minestats</code> practically becomes a dependency for some of what will hopefully be some pretty cool stuff.
		People may be encouraged to either support the pull request or install <code>minestats</code>.
		And from my perspective, would either be a bad thing?
		Even if people end up just not installing the cool mods, it&apos;ll allow the development of my subgame to continue unhindered.
		I can&apos;t help but win with this strategy, no matter how cooperative others are or aren&apos;t.
		I&apos;ve already got the new Minetest $a[API] details worked out in my head too, just not the code that will implement them.
		It&apos;ll be seamless and definitely serve more than just my current use case.
	</p>
</section>
END
);
